Feature/mqtt ha config - #178

Out of curiosity, what limitation are you running into with the current HTTP-based approach? Is there a specific use case that requires MQTT instead?

I personally prefer using MQTT, since it’s event-based rather than continuously polling every few seconds.
I also believe it’s needed for setups where Home Assistant is running on a different machine from the Raspberry Pi.
The change still keeps MQTT optional.

Thanks for putting this together, and sorry for the slow back and forth. I'd rather explain my thinking properly than leave this sitting.

Where I've landed: I'm inclined not to merge this as it stands, but I want to talk it through rather than close it silently, because it's very possible I'm missing something.

Why I'm hesitant

Pi-Somfy already has a complete MQTT interface with Home Assistant auto-discovery built in. Run it standalone with -m and the covers show up in HA automatically, with push based state updates. No YAML, no polling. So the use case you're describing is already fully supported today as far as I'm aware. It just lives in the standalone install rather than the add-on.

The add-on has intentionally been the other path: web UI and scheduler, no broker, no MQTT dependency.

• run.sh never passes -m
• the Dockerfile deliberately skips paho-mqtt
• DOCS.md points MQTT users at a standalone install

That's the add-on's reason for existing, and it works well as it is. Adding MQTT to it means two ways to do the same thing, five new options to document and support, and more surface for me to keep working across HA releases. Also more confused users trying to understand why there are parameters they don't need.

What would change my mind

Is there something the standalone install can't do for you here? If there's a real blocker, something about your setup that makes standalone impractical, I'd want to know, because that would change my view.

A smaller version I would merge

If the answer is essentially "standalone works, but running the add-on is much more convenient", I'm still open to it, just in a much leaner form. HA add-ons can declare services: - mqtt:want in config.yaml and read the broker details from the Supervisor at runtime:

MQTT_HOST=$(bashio::services mqtt "host")
MQTT_PORT=$(bashio::services mqtt "port")
MQTT_USER=$(bashio::services mqtt "username")
MQTT_PASSWORD=$(bashio::services mqtt "password")

That drops mqtt_server, mqtt_port, mqtt_user and mqtt_password entirely, leaving a single enable_mqtt toggle that's off by default (the client ID can be hardcoded). Anyone running the Mosquitto add-on ticks one box and it works. Nothing to look up, no credentials duplicated into add-on config, and far less for me to support. That version I'd be happy to merge, and I'm glad to help get it there.

One technical note either way

The sed -i "s|^MQTT_Server.*|...|" lines only replace keys that already exist in the config file. On a fresh /data/operateShutters.conf with no [MQTT] section, those values would silently never be written.

None of this is meant to dismiss the work. I appreciate you taking the time, and the polling versus events argument is a fair one. I just want to be careful about what goes into the add-on. Let me know what you think.

No worries on the back-and-forth :)
I'm running Pi-Somfy only through the add-on (Docker) - no separate standalone install.
So the add-on is the only thing controlling the Pi-Somfy service, and since it doesn't pass -m, MQTT never activates, regardless of what's in the config file.

I see the add-on as a way to expose all config options like this more accessibly, rather than needing a second, separate install just to get MQTT.

Perfect, This is exactly what I had in mind, thanks for reworking it. Nice and small.

Four things before I merge, two functional and two docs. If you can apply them and confirm it still works on your setup, that would be great.

1. Write EnableDiscovery as well

defaultConfig.conf ships EnableDiscovery = true, so a fresh install is fine. But anyone with an existing /data/operateShutters.conf where it is false or missing would get MQTT with no auto-discovery, which is the whole point of the toggle. Add it to the loop:

for entry in "MQTT_Server:${MQTT_HOST}" \
             "MQTT_Port:${MQTT_PORT}" \
             "MQTT_User:${MQTT_USER}" \
             "MQTT_Password:${MQTT_PASSWORD}" \
             "MQTT_ClientID:somfy-mqtt-bridge" \
             "EnableDiscovery:true"; do

2. Guard against a missing [MQTT] section

The else branch uses sed "/^\[MQTT\]/a ...", which silently does nothing if the section is not in the file. Add this just before the loop:

if ! grep -q "^\[MQTT\]" "${CONFIG_FILE}"; then
    printf '\n[MQTT]\n' >> "${CONFIG_FILE}"
fi

3. Add translations/en.yaml

Right now the toggle appears on the add-on Configuration screen as the raw key enable_mqtt with no explanation. A new file at Home Assistant/addon/pi_somfy/translations/en.yaml gives it a label and puts the Mosquitto requirement where people will actually read it:

configuration:
  gpio_pin:
    name: Transmitter GPIO pin
    description: GPIO pin the 433.42 MHz transmitter is wired to.
  rx_gpio_pin:
    name: Receiver GPIO pin (optional)
    description: >-
      GPIO wired to a CC1101 receiver's data output, for tracking physical
      remote button presses. Leave blank to disable the receiver.
  spi_sck:
    name: CC1101 SPI clock GPIO
    description: Only used when a receiver GPIO pin is set.
  spi_mosi:
    name: CC1101 SPI MOSI GPIO
    description: Only used when a receiver GPIO pin is set.
  spi_miso:
    name: CC1101 SPI MISO GPIO
    description: Only used when a receiver GPIO pin is set.
  spi_csn:
    name: CC1101 SPI chip-select GPIO
    description: Only used when a receiver GPIO pin is set.
  enable_mqtt:
    name: Enable MQTT
    description: >-
      Publish shutters to Home Assistant using MQTT auto-discovery, so cover
      entities appear automatically with push-based updates instead of REST
      polling. Requires the Mosquitto broker add-on to be installed and
      running. Leave off to use the web UI and custom integration only.

4. One line in DOCS.md about external brokers

The current wording explains that Mosquitto is found automatically, but not what happens if someone runs a broker outside Home Assistant. Worth adding to the MQTT section:

If your broker is not running as a Home Assistant add-on, this toggle will not
find it. Run Pi-Somfy standalone with `-m` and set the broker details in
`operateShutters.conf` instead.

Once you confirm, I'll merge. Thanks again for sticking with this.

Thanks for the detailed review - all four applied:

1. EnableDiscovery - now written alongside the other MQTT keys in run.sh, so an existing operateShutters.conf where it's false/missing gets corrected when MQTT is enabled.
2. Missing [MQTT] section guard — added before the key-writing loop, so the sed -i "/^\[MQTT\]/a ..." appends can't silently no-op on a config file that predates MQTT support.
3. translations/en.yaml - filled out with a name/description for every option (rx_gpio_pin, the SPI pins, and enable_mqtt, including the Mosquitto add-on requirement), so the Configuration tab is self-explanatory instead of showing raw keys.
4. DOCS.md - added a line under the MQTT section noting that an external (non-add-on) broker won't be found by this toggle, and that standalone -m is the way to use one.

Also caught and fixed one unrelated bug while testing: config.yaml's version was 3.0.0, which isn't a real tag on this repo (only v1.0-v3.2 exist), so the Dockerfile's clone of the Pi-Somfy source was failing outright for anyone building from scratch. Bumped it to 3.2 to match the latest tag, and updated build.sh to read the version from config.yaml instead of a second hardcoded copy, so the two can't drift apart again.

Confirmed working on my hardware: MQTT auto-discovery, the Configuration tab labels, and a fresh add-on build all check out.

BTW, I would like to merge together with #179 — I'll update that PR to be pulled from this PR's changes. #179 gives the ability to use the standard add-on repository installation rather than copying the files manually, so it'll be easier to deliver changes and upgrades.